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ABSTRACT 

METHOD AND APPARATUS FOR CREATING A DISTRIBUTED 
ELECTRONIC COMMERCE SYSTEM 

A method and system for transacting commerce in a distributed 
communications system over the Internet comprises the reception and 
transmission of shopping requests, product requests, and payment 
information between distributed Web sites. The distributed communications 
system comprises: a server system; and a customer system which is coupled 
to the server system. The server system comprises a virtual cashier for 
receiving product requests and payment infomnation. The virtual cashier 
responds to a first network address. The server system also comprises a 
virtual store for shopping. The virtual store responds to a second network 
address. The customer system allows a customer to make shopping 
requests. Java applets and servlets running at distinct .nehvork addresses 
provide much of the functionality. The system allows greater efficiencies and 
lower costs for Worid Wide Web ("WWW") merchants and for Web site hosting 
services. 
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BACKGROUND OF THE INVENTION 

1. Field of the Invention. 

The present invention relates generally to computer netv^orks and more 
particularly to methods and apparatus for providing a scalable distributed 
10 Internet commerce system. - 

2. Description of the Related Art. 

Another U.S. Pat Application dealing with related technology has been 
•filed on even date herev^ith. That application is entitled "A Method and 
15 Apparatus for Creating a Merchant Web Site for Use in a Distributed 

Electronic Commerce System" by Victor S. Moore and Glen R. Walters and is 
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assigned to International Business Machines ("IBM") with an IBM reference 
number of BC9-98-020 (referred to hereinafter as the "Development Tool 
Application"). 

The World-Wide-Web ("Web") has become immensely popular largely 
because of the ease of finding information and the user-friendliness of today's 
browsers. A feature known as hypertext allows a user to access information 
from one Web page to another by simply pointing (using a pointing device 
such as a mouse) at the hypertext and clicking. Another feature that makes 
the Web attractive is having the ability to process the information (or content) 
in remote Web pages without the requirement of having a specialized 
application program for each kind of content accessed. Thus, the same 
content is viewed across different platforms. Browser technology has evolved 
to enable the running of applications that manipulate this content across 
platforms. 

The Web relies on an application protocol called HTML (Hyper-Text 
Mark Up Language), which is an interpretative scripting language, for 
rendering text, graphics, images, audio, real-time video, and other types of 
content on a Web compliant browser. HTML is independent of client 
operating systems. Therefore, HTML renders the same content across a wide 
variety of software and hardware operating platforms. The software platforms 
include without limitation Windows 3.1, Windows NT. Apple's Copeland and 
Macintosh, and IBM's AIX and OS/2, and HP Unix. Popular compliant Web- 
Browsers include without limitation Microsoft's Internet Explorer, Netscape 
Navigator, Lynx, and Mosaic. HTML interprets links to files, images, sound 
clips, and other types of content through the use of hypertext links. Upon user 
invocation of a hypertext link to a Web page, the browser initiates a network 
request to receive the desired Web page. 
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The use of electronic commerce on the Web is growing. A variety of 
traditional larger retailers and larger mail order catalog companies have been 
offering their goods for sale electronically over the Web. Everything from the 
actual shopping to the detefmination of available inventory and the 
acceptance of payment is accomplished electronically. The merchant's Web 
site or Web storefront handles all shopping, selection, and acceptance of 
payment transactions automatically. Unlike traditional storefronts, these 
automatic capabilities enable a merchant to have its goods offered for sale 
twenty four hours a day, every day of the year (for an example of a traditional 
catalog company with its goods available via the Web refer to L.L. BEAN of 
Freeport. Maine, whose URL is vmw.llbean.com). But the ability to host retail 
merchandise on the Web is not without difficulties. 

It is difficult to integrate the major functions of electronic Web 
commerce. Three functions, in particular, are typically integrated in a retail 
Web site. The first function is the virtual presentation, using text, graphics, or 
otherwise, of a merchant's products to customers. This is sometimes called 
the "electronic storefront" or "Web storefront." or in the case of a catalog 
merchant, the "electronic catalog." The second function is the maintenance of 
inventory, stock, pricing, and availability of each product, as well as tracking 
sales and revenues. The third function is performing the electronic 
transactions for payment in a secure environment, where the collection of a 
customer's payment information, such as a credit card, is perfonmed. 
Typically, most electronic commerce sites integrate all three of these functions 
at one physical site. 

Companies desiring to do business over the Web face many problems. 
A first problem is the expense and complexity of setting up the necessary 
elements of an electronic commerce server. This difficulty includes: (1) 
hosting of the Web storefront; (2) maintenance of an inventory and financial 
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database; and (3) the roll out of a secured Transaction Server, The initial up- 
front cost is a significant barrier for nnost small businesses desiring to gain a 
presence on the Web. Therefore, a need exists to lower or even to eliminate 
the high-cost barrier typically associated with setting up electronic commerce 
5 on the Web. The cost not only involves software design and implementation, 
and setting up the necessary equipment, but the initial hardware investment 
capable of running all three elements of an electronic commerce server for 
one business. 

A second problem is meeting the requirement that the Web storefront 

10 or Web catalog be constantly up-to-date. Many businesses pay dedicated 
) personnel to update, create, and modify their Web sites. The cost of the 

service to maintain a merchant's Web site can be significant. A need exists to 
provide a merchant with the capability of easily creating, modifying, and 
updating its own Web storefront. 

15 A third problem is meeting the requirement that the Web storefront 

inventory and financial database must be maintained and updated. Sales, 
advertised specials, and other changes in pricing need to be reflected in the 
inventory database. For many smaller businesses the requirement to keep 
inventory and financial records electronically, not to mention the requirement 

20 to be electronically connected to their Web storefront, is too complex and too 
. costly. Many smaller businesses use simple written ledgers or standalone 

software applications to control their inventories and finances. For merchants 
desiring to sell goods and services over the Internet, a need exists to be able 
to have their inventory and finances maintained in a scalable fashion. In this 

25 way, as the business grows, the merchant can migrate from a pencil and 

ledger, through a stand-alone electronic database, up to a fully connected and 
automated database. 
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A fourth problem is meeting the requirement to automatically accept 
secure, electronic forms of payments. The need to have encr>/ption and 
clearance software, secure server hardware, and secure firewalls makes this 
requirement expensive. Fbr merchants desiring to set up Web storefronts, a 
need exists to be able to scale electronic payments to meet their needs. 

A fifth problem is achieving the ability to advertise to news groups and 
other Internet text-based users, as opposed to graphics-based users. Popular 
text-only viewers such as Lynx do not have graphical HTML capabilities. A 
need thus exists for merchants to be able to advertise anywhere and to 
process payment information even in text-only based electronic commerce. 

As mentioned earlier, one of the concerns for a merchant desiring to do 
electronic commerce is the Web site development. In the case of a large 
company that wants to have all three functions integrated into one Web site, 
these costs can easily exceed $1 million. In addition, even though the 
programming will usually not be done by the merchant, the merchant will have 
to devote substantial amounts of time to the layout design and to the review. 
These costs, in time and money, are significant. Smaller companies may opt 
to create their own Web sites. This undertaking can be quite difficult, 
however, for the merchant who is not a sophisticated computer user. While it 
is relatively easy to create a Web site, without competent guidance the site 
may be pooriy designed and therefore of little economic value. There is, 
therefore, a need for a development tool which simplifies the design, creation, 
and maintenance of a Web site for merchants. 

SUMMARY OF THE INVENTION 

Briefly, in accordance with one aspect of the invention, a method for 
transacting business in a distributed communications system comprises: 
receiving a shopping request at a virtual store from a customer system; and 
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sending a product request to. a virtual cashier from the virtual store. The 
distributed communications system comprises: a server system; and a 
customer system which is coupled to the server system. The server system 
comprises the virtual cashifer for receiving product requests and payment 
information. The virtual cashier responds to a first network address. The 
server system also comprises the virtual store for shopping. The virtual store 
responds to a second network address. The customer system allows a 
customer to make shopping requests. 

Briefly, in accordance with another aspect of the invention, a method 
for transacting business in the distributed communications system comprises: 
receiving product requests at the virtual cashier from the virtual store; and 
receiving payment information at the virtual cashier from the customer system. 

Briefly, in accordance with other aspects of the invention, computer 
readable media contain program instructions for implementing the above 
methods. ^ 

Briefly, in accordance with other aspects of the invention, virtual stores 
and virtual cashiers implement the above methods. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a functional block diagram of a non-distributed electronic 
commerce system for the Worid Wide Web ("WWW"), according to the prior 
art. 

FIG. 2 is a functional block diagram of a distributed electronic 
commerce system for the WWW, according to the present invention. 

FIG. 3 is a functional block diagram of another distributed electronic 
commerce system for the WWW, according to the present invention. 

FIG. 4 is a functional block diagram of another distributed electronic 
commerce system for the WWW, according to the present invention. 
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FIG. 5 is a flow diagram of the functions that are performed in a typical 
shopping experience by a VWWV customer using the distributed electronic 
commerce system depicted in FIG. 4. 

DETAILED DESCRIPTION OF AN EMBODIMENT 

1. Introduction and Overview ^ 

Referring to FIG. 1, there is shown a system 100, according to the prior 
art, in which the three functions of product presentation, database 
management, and transaction processing are contained in one server 108 and 
are, therefore, not distributed. The server 108 refers to a specific computer. 
These three functions are performed by the Web storefront 106, the inventory 
and financial database 104. and the Transaction Server 102, respectively. An 
example of a provider of this type of non-distributed service is Net.Commerce. 
It is quite possible, however, to distribute the three functions amongst two or 
more separate servers. 

FIG. 1 also illustrates a functional diagram of a computer network for 
World Wide Web ("WWW") access from customers 114, 1 16 to the server 
108. Access to the server 108 can be accomplished directly through a local 
Internet Service Provider ("ISP") 110. or through an on-line service provider 
("OLSP") 112 such as CompuServe, Prodigy, or America Online. 

One method of distributing the electronic commerce functions is to 
separate out the function of the Transaction Server from the Web storefront 
and the inventory and financial database. Referring to FIG. 2, there is shown 
a system 200 containing a Transaction Processor 1 02 on one server (the 
Transaction Server 202). and a Web storefront 106 and inventory and 
financial database 104 both on a second server (the Store Server 204). This 
may be desirable, for instance, when the Web merchant desires to maintain 
its ov^ Web storefront, whether due to the merchant's expertise, physical 


BC9-98-031 


7 


distance from the transaction service provider, or otherwise. Such a merchant 
could use any of the many hosting service providers such as CyberGate, 
Magg.Net, and UUNet. 

FIG. 3 shoves a system 300 with a further distribution, in which the 
5 database 104 is not on-line. The dashed line in FIG. 3 indicates that the 

inventory and financial system may or may not be electrically connected to the 
server. A computerized system could have an electrical interface to the serv/er 
and not be located on the server itself. Alternatively, the inventory and 
financial system may be stand alone. This may be the case if the Web 

10 merchant does not have a computerized inventory and financial database 
system, or if the merchant has a computerized database system but simply 
does not have it connected to the server. 

Referring to FIG. 2, the Store Server 204 is a conventional HTTPd 
(Hyper-Text Transfer Protocol daemon). In the preferred embodiment, it is a 

15 Sun Microsystems's Java compliant HTTPd server running Java compliant 

supporting standard servlet interfaces such as Netscape Java Server software 
or Lotus Domino Go Java software. By using a Java compliant 
implementation, the same code can run on a variety of operating systems 
supporting the Java Virtual Machine including without limitation Solaris, Unix. 

20 AIX. OS/2, and Windows 95/NT operating systems. 

As an overview, and referring to FIG. 3, the Transaction Server 202 
now does not host the Web storefront 1 06. However, the Transaction Server 
202 need not store any of the inventory or financial data nor any other 
information on the product line of the merchant. All the information that the 

25 Transaction Server 202 needs in order to process a purchase (for example, 
from customer 114) is sent to it every time that a purchase is requested. The 
Transaction Server 202 verifies that the customer 114 wants to make a 
purchase of a specific "shopping basket" of products and prompts the 
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customer 114 for payment information. Either the merchant or the 
Transaction Server 202' can perform the tasks of credit card verification, 
authorization of the total purchase amount, and funds transfer. When the 
Transaction Server 202 has finished its tasks, it then provides the merchant 
v^ith a status report of the transaction and the customer with a confirmation. 

The Web storefront 106 acts as the virtual store for the customer 114, 
and contains v^hatever information the merchant has built into the Web-site 
(e.g. pictures, prices, search engines, etc.). In the Development Tool 
Application, there is provided a Development Tool for designing the Web 
storefront 106. This tool greatly simplifies the task of creating the Web 
storefront initially and of modifying it and updating it. The Tool also ensures 
that the operation with the Transaction Server 202 is seamless for the 
customer 1 14. 

The Tool derives much of its utility from the fact that it contains a series 
of templates, tailored to different industries, for creating pages. The fields on 
these templates can be filled with text, or with images from clip art (also 
included with the tool) or can be tailored to suit a specific merchant's needs. 
The task is greatly simplified by the inclusion of a prompting mode in which 
the tool will actually step a user through the process. As an additional 
tailoring feature, the tool can be adapted to whatever "look and feel" the 
customer may desire. The customer may want to match the look and feel to 
that of other applications that the customer uses, or may simply fee! more 
comfortable with another look and feel. 

In the preferred embodiment, the Tool, as either an applet which would 
run on top of a browser or as an application, would be downloaded from a 
Store Builder Server. Referring to FIG. 4. there is shown a distributed 
electronic commerce system 400 with a Store Builder Server 402. The 
merchant would download the Java wizard applet to build the pages for the 
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Web storefroriL, which will reside on the Store Server 204. The Store Builder 
Server 402 would also contain Java servlets that would receive the HTML 
from the wizard applet for the storefront pages that the merchant designed 
and would build the store pages from this HTML. This, of course, would 
5 happen when the merchant initially designed the pages, or whenever the 

merchant updated or modified them. The servlet, on the Store Builder Server 
402, would then publish the Web storefront pages wherever the merchant 
designates. The commerce system is thereby distributed even more, by 
separating (if desired) the tasks associated with designing the merchant's 
10 Web site. In alternate embodiments, the Tool could be downloaded from the 
Transaction Server 206 or obtained on a CD ROM or other recordable 
medium. 

2. Detailed Description of the Shopping Flow 

15 . Referring to FIG. 5. flow diagram 500 illustrates the high-level functions 

that each of the servers (see FIG. 4). or each of the Web sites hosted thereon, 
performs in a typical shopping experience of a customer. 

The customer, using a browser, goes to the Store Server and begins 
shopping, that is, browsing the content of the Web storefront 502. When the 

20 customer finds a product that the customer would like to buy, he selects that 
product 504. The Store Server then jumps to the Store Builder Server by 
using a Uniform Resource Locator ("URL") 506. The URL, called a price URL, 
contains all of the relevant information on the product, and all the information 
necessary to build a "Buy Page/ The relevant.product information includes a 

25 picture of the product, the product's price, and a description of the product. 
The Store Builder Server receives the price URL, which is encrypted, 
and a Java "Buy Page" servlet builds a Buy Page from the received HTML 
508. The customer can now either accept by selecting the option that puts the 
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product in the customer's "shopping basket," or cancel the buy 510. If the buy 

operation is canceled, then the customer is returned to the Store Server and 

can continue shopping. If the buy operation is accepted the Store Builder 

* » 

Server then presents the Customer with his entire shopping basket up to that 
5 point, which the Store Builder Server creates and maintains. The customer 
can now delete items from the basket, change the quantities, "purchase" the 
entire basket, or return to the Store Server to continue shopping 512. It 
should be clear that the previous buy operation was equivalent to dropping the 
product in the shopping basket, and the purchase operation is equivalent to 

10 going to the check-out counter. The Java servlet that maintains the shopping 
basket could use any of a variety of means, including without limitation 
tracking the Web customer's browser address or prompting the customer for a 
name, for keeping track of which customer belongs to which basket. 

The customer leaves his shopping basket page by either making a 

1 5 purchase or continuing shopping. If the customer decides to make the 

purchase, he is hyperlinked to the Transaction Server 514. The Transaction 
Server, thus, is not involved until money is ready to be transferred. The 
Transaction Server, therefore, immediately establishes a secure link between 
itself and the customer's browser 516. Any security protocol could be used, 

20 but the secure sockets layer ("SSL") protocol is preferred. After establishing a 
secure link, the Transaction Server prompts the customer for the necessary 
identification, delivery, and payment information 518. 

In an altemate embodiment, the functions of establishing a secure link 
and getting the customer's payment information could be done in the Store 

25 Builder Server. The Transaction Server would then receive this information 
from the Store Builder Server, in an encrypted form, and decrypt tt. This 
would provide an embodiment in which the Transaction Server did not need to 
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interact in real-time with the customer, but merely provide a confirmation if 
desired. 

The Transaction Server may. optionally, verify the credit card 
information, authorize the payment amount, and transfer the funds to the 
5 merchant's account 520. The Transaction Server would do this by using a 
third party credit card clearinghouse such as IC Verify or Automated 
Transaction Services (ATS). The merchant need not request this service from 
the Transaction Server, however. Low-volume merchants may prefer simply 
to be e-mailed (securely) or faxed the entire purchase order, and perform 
10 these functions themselves, thereby saving the associated cost that the 

transaction service provider would have charged. Additionally, the merchant 
may prefer to check his inventory before charging the customer. 

In either case, the Transaction Server will notify the merchant of the 
status of the transaction and supply all of the product, customer, deliver^', and 
15 payment information 522. If the customer provided an e-mail account, then 
the Transaction Server will also send a confirmation of the transaction to the 
customer 522. 

The Transaction Server could also perform, in alternate embodiments, 
the functions of the Store Builder Server. In such an embodiment, the price 
20 URL would hyperlink to the Transaction Server which would contain the Java 
servletthat builds the Buy Page, and the Java servlet that maintains the 
shopping basket 

3. High-Level Functions Performed by each Server 
25 Having explained the sequence of events and communications 

between the servers during a typical transaction, it will be instructive to 
summarize, individually, the functions performed by each of the servers. 
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a. Functions Performed by the Store Server 

The Web storefront performs one basic service, and that is to present 
the multi-media content to the customer in order to let the customer shop. 
The format of-this presentartion is controlled by the merchant, and can easily 
5 be designed using the Development Tool disclosed in the Development Tool 
Application mentioned earlier. 

The Web storefront could have a variety of other functions associated 
with it. For instance, background information on the merchant, contact 
information, news items of interest to the merchant's customers, etc. can all 
10 be displayed on the Web storefront. 

As discussed earlier, the merchant can control inventory and financial 
data in any manner desired. If the merchant utilizes a computer-based 
database, then the merchant can also interface this to the Web storefront. 
This could be used to supply information on backorders, quantities available, 
15 current prices, etc. to the customer. In a sophisticated system, the database 
could even possibly be interfaced electronically with the Transaction Server by 
creating a program that processes the e-mail order notifications sent by the 
Transaction Server. 

20 b. Functions Performed by the Store Builder Server 

The first major function of the Store Builder Server is to help the 
merchant get his Web storefront up and running. The Store Builder Server 
first provides the wizard applet or application, which allows the merchant to 
create his Web storefront. The Store Builder Sprver then accepts the HTML 

25 for the Web storefront from the merchant and builds the Web storefront. The 
Store Builder Server then publishes the Web storefront at a site of the 
merchant's choosing. The merchant supplies a user ID and a password to the 
Store Builder Server, and the Store Builder Server uses file transfer protocol 
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("FTP"), or some other service, to send the Web pages to the chosen hosting 
site. 

The second major function of the Store Builder Server is to provide the 
shopping basket for the customer. The Store Builder Server places each 
product in the basket as the customer selects or buys them and holds them 
until the customer is ready to check out. At that point, the Store Builder 
Server transfers control, and the relevant information, to the Transaction 
Server. 

c. Functions Performed by the Transaction Server 
The Transaction Server has only one general responsibility, and that \t 
to process the customer's infonmation. This involves getting the information 
from the customer and transferring it to the merchant. As explained earlier, it 
may also involve verifying the information, getting the purchase authorized, 
and transferring the funds. Additionally, the Transaction Server can also send 
the customer a confirmation of the transaction. 

Also of importance is the fact that the Transaction Server, like the Store 
Builder Server, need not know v^here the Store Server is located. That is, the 
Transaction Server does not require that the Store Server, or even the Store 
Builder Server, be at any particular Internet address. Even in an embodiment 
in v^hich the Transaction Server also performed the functions of the Store 
Builder Server, the Transaction Server v^ould not need to knov^ v^here the 
Store Server was located. In such a case, the Transaction Server would 
receive the price URL with the product information. It is evident, however, that 
once the price URL is sent, the location of the Store Server (or rather, the 
location from which the price URL was sent) is, and needs to be, known. 
Knowing where the price URL was sent from (typically a page from the Store 
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Server) allows the Transaction Server or the Store Builder Server to hyperlink 
the Web customer back there to continue shopping. 

4. Advantages associated with the Preferred Embodiment 
a. Advantages for the Merchant 

The preferred embodiment has a number of significant advantages for 
the merchant who desires to participate in electronic commerce. First, it is 
less expensive than the non-distributed system. The merchant need only buy 
the Development Tool to create the Web site, pay for hosting of the Web 
storefront at an ISP of the merchant's choice, and pay the charge for the 
transaction services (usually based on volume). Hosting fees can be as low 
as twenty dollars per month depending on the memory and the bandwidth 
required. 

Second, it is much simpler to create the Web storefront than to create 
an ordinary electronic commerce Web site. The Development Tool, which is 
described in the Development Tool Application mentioned earlier, allows the 
merchant to design, build, and publish a web site in a short period of time. It 
also makes it easy to modify the site.. This is to be compared with the process 
of hiring a professional to do it, or with educating oneself about the process 
and doing it alone. 

Third, rt offers a great deal of control to the merchant. The merchant . 
can redesign the site, change prices, decide to have a sale, add or delete 
products, update the site with pictures or other content, expand the number of 
places that offer the products for sale on-line, change hosting sites, and much 
more, all without even notifying the Store Builder Server or the Transaction 
Server. The merchant has almost complete control. The merchant can do 
anything the merchant wants with the site or with the information on the site. 
The only restriction is that the price URLs, which allow the Store Builder 
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Server to build the Buy Pages, have to be included on the site, or elsev.-here, 
in order for the Web customer to place an order. The merchant can even 
totally remove the Web storefront, and simply post the price URLs on news 
groups or on another web site. 
5 It should be clear that the distributed electronic commerce system 

offers significant advantages to all merchants, particularly those of small to 
medium size. 

b. Advantages for the Transaction Service Provider 

•^0 There are a number of distinct advantages that this embodiment offers 

the transaction service provider. First, overhead is minimized. Much of the 
overhead and cost of hosting a commerce Web site comes from the 
bandwidth requirement. Every time that a Web site gets a "hit." information 
must be transmitted. If the transaction service provider chooses not to host 

1 5 the Web storefronts, then it does not have to process any of the hits 

associated with all of the shopping that occurs on the Web storefronts. The 
bandwidth usage will be even lower because, presumably, nnany of the 
merchants will choose to do their own credit card verification, thereby 
eliminating those transmissions as well. Further, in embodiments utilizing a 

20 Store Builder Server, the Transaction Server does not need to maintain the 
shopping baskets,' nor process the hits associated with each of the buys. 

Second, the amount of memory required is minimized. The Transaction 
Server does not need to host any of the Web storefronts, nor does it need to 
maintain any shopping baskets nor any infomri^tion on the products being 

25 offered for sale by the merchants, nor does it need to keep any data regarding 
the Store Servers. In the preferred embodiment, the primary merchant-related 
data that the Transaction Server needs to store is a list of all of the registered 
merchants and their contact information. Clearly, however. Transaction 
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Servers will want to keep track of sales so that they can bill the merchant's for 
their services, and may want to store additional information and statistics 
about the merchants as well. 

Third, the barrier to entering into electronic commerce is lowered for the 
merchants. This benefits the transaction service provider because it opens up 
a whole new group of potential customers. These potential customers are the 
merchants who could not afford to do non-distributed Web commerce. 

Fourth, the technique is also scalable. The transaction service provider 
can serve a much larger number of merchants with a given Transaction 
Server (due to the advantages above). If the number of sales grows and a 
particular Transaction Server reaches its threshold in memory or bandwidth, 
then the transaction service provider can simply add another Transaction 
Server and have the Store Builder Server direct some of the traffic to it. The 
Store Builder Server is also scalable, and if an additional server is needed due 
to volume it can be added. In that case, the provider can use the new server 
for future merchants or even direct current merchants to create any future 
price URLs (for new products or changes for existing products) using the new 
server. 

5. Virtual Commerce 

It is useful to broaden some of the concepts introduced or discussed 
above in order to see how they fit into the broader concept of virtual 
commerce. The merchant's web site, that is the actual web pages, can be 
considered to be a virtual store. The virtual store could span across one or 
more physical servers or computers, and these servers can collectively be 
referred to as the store server system. Analogously, the transaction service 
provider's web site can be considered to be a virtual cashier, spanning across 
a cashier server system comprised of one or more servers. The store builder 
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jserver web site could be considered to be yet a third virtual entity, or it can 
more simply be considered to be either part of the virtual store or the virtual 
cashier. 

Numerous criteria could be developed to determine when these virtual 
5 entities could be considered to be distributed. Some such criteria include: 
different servers or computers hosting the web sites; different processors • 
executing the instructions associated with each web site, with each processor 
potentially accessing the same memory; or each web site merely responding 
to a different network address, possibly residing in the same memory on a 

10 common server, running on the same processor, and accessing the network 
over the same hardware such as a communications card. Each of these 
ideas is meant to be encompassed in the present application when referring to 
distributed systems. For this reason, the computers or servers that are part of 
the store server system may also form part of the cashier server system. 

15 These virtual stores and cashiers are presently displayed over the 

Wortd Wide Web and the Internet, but future networks will surely arise for 
which virtual commerce will be applicable. Further, the present means of 
accessing and displaying virtual entities will change. Presently, web browsers 
running on personal computers processing HTML pages with HTTP requests 

20 ^ and using URLs to link between pages is the preferred mechanism or system 
for customers to access the content. Software and computer technology will 
quickly replace many of these standards. Additionally, other technologies 
involving optics, magnetics, and other sciences could also produce viable 
methods of accessing and displaying virtual entities. Each of these potential 

25 advances, when used to enable a distributed commerce system over a 

network, can be viewed as a further embodiment of the present invention. 
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6. General Implementation 

Distributed commerce systems, in accordance with the present 
invention can be, at least partially, implemented by hardware, software, or a 
combination of both. This may be done for example, by Java applets and 
servlets running on a variety of host equipment. Moreover, this functionality 
may be embodied in computer readable media such as 3.5 inch diskettes to 
be used in programming an information-processing apparatus to perform in 
accordance with the invention. This functionality may also be embodied in 
computer readable media such as a transmitted waveform to be used in 
transmitting the information or functionality. 

Although a specific embodiment of the invention has been disclosed, it 
will be understood by those having skill in the art that changes can be made to 
this specific embodiment without departing from the spirit and scope of the 
invention. The scope of the invention is not to be restricted, therefore, to the 
specific embodiment, and it is intended that the appended claims cover any 
and all such applications, modifications, and embodiments within the scope of 
the present invention. 
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1 3. In a distributed communications system for transacting business 

2 comprising a customer system for allowing a customer to make ^ 

3 shopping requests, and a server system which is coupled to the 

4 customer system, wherein the server system comprises a virtual store 

5 for shopping, and wherein the virtual store responds to a first network 

6 • address; a virtual cashier for receiving product requests and payment 

7 information, wherein the sen/er system comprises the virtual cashier, 

8 and wherein the virtual cashier responds to a second network address, 

9 the virtual cashier comprising: 

10 first receiving means for receiving product requests from the 

1 1 virtual store; 

12 second receiving means for receiving payment information from 

1 3 the customer system. 

1 4. The virtual cashier of claim 3, wherein the first receiving means 

2 comprises a means for receiving a URL containing information about a 

3 single product. 

1 5. The virtual cashier of claim 3. wherein the first receiving means 

2 comprises a means for receiving a list of products which a customer 

3 has selected. 

1 6. The virtual cashier of claim 3. wherein the second receiving means 

2 comprises a means for securing the transmission link between the 

3 virtual cashier and the customer. 
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7. In a distributed communications system for transacting business. 

wherein the communications system comprises a customer system for 
allowing a customer to make shopping requests, and a server system 
which is coupled to the customer system; wherein the server system 
comprises a virtual cashier for receiving product requests and payment 
information, the virtual cashier responding to a first network address, 
and a virtual store for shopping, the virtual store responding to a 
second network address; a method for transacting business comprising 
the steps of: 

receiving a shopping request at the virtual store from the 
customer system; and . 

sending a product request to the virtual cashier from the virtual 

store. 
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1 8. In a distributed communications system for transacting business. 

2 wherein the communications system comprises a customer system for 

3 allowing a customer to make shopping requests, and a server system 

4 which is coupleqi to the customer system; wherein the server system 

5 comprises a virtual cashier for receiving product requests and payment 

6 " information, the virtual cashier responding to a first network address. 

7 and a virtual store for shopping, the virtual store responding to a 

8 second network address; a method for transacting business comprising 

9 . the steps of: 

^0 receiving product requests at the virtual cashier from the virtual 

^ 11 store; and 

12 receiving payment infonmation at the virtual cashier from the 

1 3 customer system, 

1 9. The method of claim 8, further comprising the steps of: 

2 sending notification of the transaction to the owner of the virtual 

3 store; and 

4 sending confinmation of the transaction to the customer. 


) 
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1 10. In a distribuied communications system for transacting business. 

2 wherein the communications system comprises a customer system for 

3 allowing a customer to make shopping requests, and a server system 

4 which is coupled to the customer system; wherein the server system 

5 comprises a virtual cashier for receiving product requests and payment 

6 information, the virtual cashier responding to a first network address, 

7 and a virtual store for shopping, the virtual store responding to a 

8 second network address; a computer readable medium containing 

9 program instructions for transacting business, the program instructions 
^ 10 comprising instructions for: 

1 1 receiving a shopping request at the virtual store from the 

12 customer system; and 

1 3 sending a product request to the virtual cashier from the virtual 

14 store. 
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1 11. In a distributed communications system for transacting business. 

2 wherein the communications system comprises a customer system for 

3 allowing a customer to make shopping requests, and a server system 

4 which is coupled to the customer system; wherein the sender system 

5 comprises a virtual cashier for receiving product requests and payment 

6 ' information, the virtual cashier responding to a first network address. 

7 and a virtual store for shopping, the virtual store responding to a 

8 second network address; a computer readable medium containing 

9 program instructions for transacting business, the program instructions 
10 comprising instructions for: 

) 1 1 receiving product requests at the virtual cashier from the virtual 

12 store; and 

13 receiving payment information at the virtual cashier from the 

14 customer system. 

1 12. The medium of claim 11, further comprising instructions for: 

2 sending notification of the transaction to the owner of the virtual 

3 store; and 

4 sending confirmation of the transaction to the customer. 


) • 
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